IPTV (Internet Protocol Television) Internet Protocol Television, generally referred to as an interactive Web television, is a manageable multimedia service such as television/video/text/graphics/data delivered over an IP network to provide QoS (quality of service)/quality of experience (QoE), security, interactivity, and reliability. The IPTV technology integrates multiple technologies such as Internet, multimedia, and communication, uses a broadband network as an infrastructure, uses a home television set, a personal computer, a mobile phone, and so on as main display terminals, and provides multiple interactive multimedia services including digital television programs to a user through an IP protocol. The IPTV is mainly characterized in that it changes the traditional one-way broadcast media transmission manner, enables the user to receive media on demand, and implements real-time interaction between the user and the media content provider, thus better satisfying personalized requirements of the user.
A video share (Video Share) service refers to a video share service initiated by the user to the peer in a call process. The shared object may be a video collected in real time by a mobile terminal through a camera, or may be a video clip file stored on the terminal. In the call process, the user may randomly initiate and terminate the service.
Later, the share technology is extended. Shared content is not limited to videos, and discrete media may also be shared, which are collectively referred to as content share (Content share).
Normally, content is shared through the following process:
(1-2) A share initiating terminal initiates an INVITE request, where the INVITE request indicates the media type to be used. The request is forwarded to a share receiver through an application server (Application Server, “AS”). An Accept-Contact header field carries a “+g.3gpp.cs-voice” feature identifier, indicating that a video share service is initiated.
(3-5) A share receiving terminal receives the INVITE request of the share initiator, and sends a 183 message to the AS, where SDP information in the message includes a media stream type and encoding manner that are received by the receiving terminal. The AS sends a PRACK message to the share receiving terminal after receiving the 183 message, and the share receiving terminal sends a 200 OK response with respect to the PRACK.
(6-8). The AS sends a 183 request to the share initiating terminal; the share initiating terminal sends a PRACK message to the AS after receiving the 183 message; the AS sends a 200 OK response with respect to the PRACK. There is no time sequence for this step and steps (3-5).
(9-10) After reserving resources successfully, the share initiating terminal sends an UPDATE message to notify the share receiving terminal.
(11-12) The share receiving terminal receives the UPDATE message, and sends a 200 OK response message to the share initiator after the resources of the share receiving terminal are reserved successfully.
(13-14) The share receiving terminal sends a 180 message to the share initiating terminal, and prompts that the share receiving terminal has received the request message.
(15-16) The share receiver user accepts sharing, and the share receiving terminal sends a 2000K message to respond to the INVITE message.
(17-18) The share initiating terminal sends an ACK message to acknowledge session establishment. The share initiating terminal shares a real-time video through an RTP packet.
(19-20) A share terminal sends a BYE message to end video share.
(21-22) The terminal receiving the BYE message sends a 200 OK response with respect to the BYE message.
From the perspective of service use, the content share performed in the IPTV system should support the solution for sharing a program watched on the current device. However, the solution of the prior art does not provide a solution for sharing content on demand (Content on Demand, “CoD”) currently watched by the user. Meanwhile, for a program being watched, and especially for a CoD program, the program may be switched between different terminals due to requirements of the user (for example, the user watches the program at home, and transfers the program to a mobile phone, or vice versa). The prior art may satisfy session continuity when watched IPTV content is switched between different terminals. However, if the user shares the IPTV content watched on a current terminal, in the prior art, the content share AS cannot perceive session transfer, that is, when session transfer occurs on the content share sender, because what concerns the content share AS is the initiating terminal specified when the content share is initiated, the information obtained by the content share AS is that the terminal where the shared content is located quits the watched program (actually, the user of the content share initiator does not quit the program), and therefore, the share operation to the peer is also terminated. As a result, the share session is interrupted and cannot be continued with the program operation of the player after transfer.